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Amendments to the Claims : 

This listing of claims will replace all prior versions, and listings, of claims in the application: 
Listing of Claims : 

1. (currently amended) A method comprising: 

monitoring performance of a network application at a demarcation point in a network by 
generating collectin g , at the demarcation point, data indicative of a first network latency condition 
between a first TCP host on a first side and the demarcation point and a second networ k latency 
condition between a second TCP host on a second side and the demarcation point; and 

determinin g, based on analysis of the data indicative of the first and second network latency 
conditions, a location of a performance problem associated with the network application identified 
as a result of monitoring performance, the location being with respect to the demarcation point. 

2. (Previously presented) The method defined in Claim 1 further comprising mediating 
between infrastructure of the network managed by the source provider and customer-managed 
infrastructure of the network. 

3. (Previously presented) The method defined in Claim 1 further comprising mediating 
between a local area network (LAN) infrastructure of the network and wide area network (WAN) 
infrastructure of the network 

4. (Previously presented) The method defined in Claim 1 wherein monitoring 
performance of the network application comprises measuring end-to-end performance of the 
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network application with respect to the network. 

5. (Previously presented) The method defined in Claim 1 wherein monitoring 
performance of the network application comprises measuring at least one of quantitative and 
qualitative performance of the network application. 

6. (Currently amended) The method defined in Claim 1 . wherein the demarcation point 
is located between a customer network and a provider network, and wherein monitoring 
performance of the network application comprises measuring congestion on a the customer 
network and a the provider network at the demarcation point between the customer network and 
the provider network. 

7. (Previously presented) The method defined in Claim 6 wherein measuring 
congestion includes identifying a class of traffic being affected. 

8. (Previously presented) The method defined in Claim 1 wherein monitoring 
performance comprises measuring network availability. 

9. (Previously presented) The method defined in Claim 1 wherein the performance 
problem comprises discarding packets. 

10. (Previously presented) The method defined in Claim 1 wherein the performance 
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problem comprises retransmission that slows overall response time. 

11 . (currently amended) The method defined i n Claim 1 , wherein the first and second 
network latency conditions are expressed as congestion index values, the method further 
comprising: comparing congestion index values over time. 

12. (Previously presented) The method defined in Claim 11 further comprising 
identifying the problem based on a ratio of the congestion index on a provider-controlled portion of 
the network versus the congestion index on a customer-controlled portion of the network being 
different. 

13. (Previously presented) The method defined in Claim 11 further comprising 
identifying the problem based on a change in a ratio of the congestion index on a provider- 
controlled portion of the network versus the congestion index on a customer-controlled portion of 
the network being different. 

14. (Previously presented) The method defined in Claim 11 further comprising 
identifying the problem based on a same amount of change occurring in the congestion index values 
on a provider-con trolled portion of the network and a customer-controlled portion of the network. 

15. (Previously presented) The method defined in Claim 1 further comprising: 
measuring congestion index values; and 
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detecting variances in the congestion index values over time for a network time period; and 
identifying the problem based on detected variances in the congestion index. 

16. (Previously presented) The method defined in Claim 1 further comprising: 
measuring congestion index values; 

detecting variances in the congestion index over time between different types of traffic; and 
identifying the problem based on detected variances in the congestion index. 

17. (Previously presented) The method defined in Claim 1 further comprising: 
comparing measurement values over time. 

18. (Previously presented) The method defined in Claim 17 further comprising 
identifying a problem based on a ratio of a measurement value on a provider-controlled portion of 
the network versus a measurement value on a customer-controlled portion of the network being 
different. 

19. (Previously presented) The method defined in Claim 17 further comprising 
identifying a problem based on a change in a ratio of a measurement value on a provider-controlled 
portion of the network versus a measurement value on a customer-controlled portion of the 
network being different. 

20. (Previously presented) The method defined in Claim 17 further comprising 
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identifying a problem based on change in measurement values on a provider-controlled portion of 
the network and a customer-controlled portion of the network, where the change is by the same 
amount. 

21. (Previously presented) The method defined in Claim 1 further comprising: 
generating measurement values; and 

detecting variances in the measurement values over time for a network time period. 

22. (Previously presented) The method defined in Claim 1 further comprising: 
generating measurement values; and 

detecting variances in the measurement values over time for different types of traffic. 

23. (Previously presented) The method defined in Claim 1 wherein monitoring 
performance of the network application comprises characterizing performance of the network 
application using one or more metrics. 

24. (Previously presented) The method defined in Claim 23 wherein the one or more 
metrics comprises a delay metric characterizing delay associated with end-to-end traffic in the 
network. 

25. (Previously presented) The method defined in Claim 23 wherein the one or more 
metrics comprises a server delay metric characterizing delay of a server in responding to a request 
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associated with the network application. 

26. (Previously presented) The method defined in Claim 23 wherein the one or more 
metrics comprises packet counts and data rates. 

27. (Previously presented) The method defined in Claim 23 wherein the one or more 
metrics comprises frame relay counts. 

28. (Previously presented) The method defined in Claim 1 further comprising: 
monitoring customer network delay; and 

monitoring provider network delay. 

29. (Previously presented) The method defined in Claim 28 wherein a network device at 
the demarcation point monitors the customer network delay and the provider network delay as half 
round trip delays. 

30. (Previously presented) The method defined in Claim 28 wherein the network device 
monitors inbound and outbound customer network delays associated with operation of the 
network application, inbound and outbound provider network delays associated with operation of 
the network application, and host latency associated with operation of the network application, 
and combines results of monitoring to CTeate an indication of the delay associated with using the 
network application in the network. 
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31. (Currently Amended) A method comprising: 

providing a demarcation point with respect to a network application provided by a provider 
in a network; a&d 

employing at least one service-level agreement between the provider of the network 
application and a customer with responsibility for management of performance problems 
associated with the network application based on the demarcation poin t; and 

monitoring performance of the network application at the demarcation point in a network 
by generating, at the demarcation point, data indicative of a first network latency condition 
between a first TCP host on a first side and the demarcation point and a second network latency 
condition between a second TCP host on a second side and the demarcation poinL 

32. (Previously presented) The method defined in Claim 31 further comprising: 
monitoring compliance with the at least one service-level agreement; and 

sending a notification if the service-level agreement is in one condition of a group consisting 
of the service-level agreement is being violated or the sendee-level agreement is within a threshold 
of being violated. 

3 3 . (Currently amended) A method comprising: 

a network device generating collecting data related to operation of a network application at 
a demarcation point in a network on behalf of a provider, wherein the data is indicative of a first 
delay between a first TCP host on a first side and the demarcation point and a second delay 
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between a second TCP host on a second side and the demarcation point; and 

the provider using the data generated collected at the demarcation point to determine 
whether a problem associated with the operation of the network application is a responsibility of 
the provider. 

34. (Currently amended) The method defined in Claim 33 wherein the provider uses 
data generated collected at the demarcation point to correct an identified problem in the network. 

35. (Currently amended) The method defined in Claim 33 wherein the provider uses 
data generated collected at the demarcation point to indicate to a user a need for an additional 
resource. 

36. (Previously presented) The method defined in Claim 35 wherein the additional 
resource comprises additional bandwidth. 

37. (Previously presented) The method defined in Claim 35 wherein the additional 
resource comprises additional server capacity. 

38. (Currently amended) The method defined in Claim 33 wherein the provider uses 
data generated collected at the demarcation point to identify a service to offer to a customer. 

39. (Currently amended) A network device for use at a demarcation point in a network, 
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the network device comprising: 

a measurement engine to take measurements at the demarcation point and record 
information indicative of delays occurring in the network, wherein the delays correspond to a first 
delay between a first TCP host on a first side and the demarcation point and a second delay 
between a second TCP host on a second side and the demarcation point, the measurement engine to 
generate a measurement value in response to the information regarding delays; 

a memory coupled to the measurement management engine to store the information 
indicative of the delays occurring in the network, including the measurement value; and 

management control coupled to the memory to access the information indicative of the 
delays occurring in the network and to determine if a problem exists in the network that is a 
responsibility of a service provider. 

40. (Previously presented) The network device defined in Claim 39 wherein the 
measurement engine performs measurements with respect to at least one of a group that includes 
network delays, server delays, bits per second, lost packets, retransmission counts, end-to-end 
delays. 

41. (Previously presented) The network device defined in Claim 39 wherein the 
management control notifies the service provider about the problem. 

42. (Previously presented) The network device defined in Claim 39 wherein the 

measurement engine records times associated with encountering packets and acknowledgement of 
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the packets to generate a measurement value. 

43. (Currently Amended) The network device defined in Claim 39 wherein the 
measurement engine monitors performance of the a network application by comprises measuring 
end-to-end performance of the network application with respect to the network. 

44. (Currently Amended) The network device defined in Claim 39 wherein the 
measurement engine monitors performance of she a network application by compriceo measuring 
quantitative performance of the network application. 

45. (Currently Amended) The network device defined in Claim 39 wherein the 
measurement engine monitors performance of die a network application by e omprises measuring 
congestion. 

46. (Previously presented) The network device defined in Claim 45 wherein the 
measurement engine measures congestion includes identifying a class of traffic being affected in 
order to solve a customer problem or provide a service to a customer to address the problem. 

47. (Currently Amended) The network device defined in Claim 39 wherein the 
measurement engine monitors performance by comprises measuring network availability. 

48. (Previously presented) The network device defined in Claim 39 wherein the 
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performance problem comprises discarding packets. 

49. (Previously presented) The network device defined in Claim 39 wherein the 
performance problem comprises retransmission that slows overall response time. 

50. (Previously presented) The network device defined in Claim 39 wherein the 
management control compares congestion index values over time. 

51. (Currently Amended) The network device defined in Claim 50 wherein the 
management control identifies the problem based on a ratio of the congestion index on a provider- 
controlled portion of the network versus the congestion index on a customer- control led portion of 
the network being different . 

52. (Currently Amended) The network device defined in Claim 50 wherein the 
management control identifies the problem based on a change in a ratio of the congestion index on a 
provider-controlled portion of the network versus the congestion index on a customer-controlled 
portion of the network being different . 

53. (Previously presented) The network device defined in Claim 50 wherein the 
management control identifies the problem based on a same amount of change occurring in the 
congestion index values on a provider-controlled portion of the network and a customer-controlled 
portion of the network. 
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54. (Currently Amended) The network device defined in Claim 38 39 wherein the 
measurement engine measures generates congestion index values, and the management control 
detects variances in the congestion index values over time for a network time period and identifies 
the problem based on detected variances in the congestion index. 

55. (Currendy Amended) The network device defined in Claim 38 39 wherein the 
measurement engine measures generates congestion index values, and the management control 
detects variances in the congestion index over time between different types of traffic and identifies 
the problem based on detected variances in the congestion index. 

56. (Currendy Amended) The network device defined in Claim ^8 39 wherein the 
management tontrol compares measurement values over time. 

57. (Currendy Amended) The network device defined in Claim 56 wherein the 
management control identifies a problem based on a ratio of a measurement value on a provider- 
controlled portion of the network versus a measurement value on a customer-controlled portion of 
the network being different . 

58. (Currendy Amended) The network device defined in Claim 56 wherein the 
management control identifies a problem based on a change in a ratio of a measurement value on a 
provider-controlled portion of the network versus a measurement value on a customer-controlled 
portion of the network being different . 
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59. (Previously presented) The network device defined in Claim 56 wherein the 
management control identifies a problem based on change in measurement values on a provider- 
controlled portion of the network and a customer- controlled portion of the network, where the 
change is by the same amount. 

60. (Currently Amended) The network device defined in Claim 38 39 wherein the 
measurement engine generates measurement values, and the management control detects variances 
in the measurement values over time for a network time period . 

61. (Currently Amended) The network device defined in Claim £S 39 wherein the 
measurement engine generates measurement values, and the management control detects variances 
in the measurement values over time for different types of traffic. 

62. (Currendy Amended) The network device defined in Claim 3& 39 wherein the 
measurement engine characterizes performance of the a network application using one or more 
metrics. 

63. (Previously presented) The network device defined in Claim 62 wherein the one or 
more metrics comprises a delay metric characterizing delay associated with end-to-end traffic in 
the network. 

64. (Previously presented) The network device defined in Claim 62 wherein the one or 
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more metrics comprises a server delay metric characterizing delay of a server in responding to a 
request associated with the network application. 

65. (Previously presented) The network device defined in Claim 62 wherein the one or 
more metrics comprises packet counts and data rates. 

66. (Previously presented) The network device defined in Claim 62 wherein the one or 
more metrics comprises frame relay counts. 

67. (Currently Amended) The network device defined in Claim 38 39 wherein the 
measurement engine monitors customer network delay and provider network delay. 

68. (Previously presented) The network device defined in Claim 67 wherein the 
measurement engine monitors the customer network delay and the provider network delay as half 
round trip delays. 

69. (Currently Amended) The network device defined in Claim iS 39 wherein the 
measurement monitors inbound and outbound customer network delays associated with operation 
of the a network application, inbound and outbound provider network delays associated with the 
operation of the network application, and host latency associated with the operation of the 
network application, and wherein the management confrol combines results of monitoring to 
create an indication of the delay associated with using the network application in the network. 
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70. (Currently Amended) The necvvork device defined in Claim 38 39 further 
comprising 

a classification engine to classify traffic in a traffic flow on the network; 
a response time block to monitor response time; and 

a shaping block to shape traffic, wherein the measurement engine is communicatively 
coupled to the classification engine, the response time block, and the shaping block to obtain 
information to create measurements. 

71. (Currently amended) An architecture comprising: 

a network device for use in a network at a demarcation point, the network device 
comprising 

a measurement engine to take measurements at the demarcation point and record 
information indicative of delays occurring in the network, wherein the delays correspond to a first 
delay between a first TCP host on a first side and the demarcation point and a second delay 
between a second TCP host on a second side and the demarcation point, the measurement engine to 
generate a measurement value in response to the information regarding delays, 

a memory coupled to the measurement management engine to store the information 
indicative of the delays occurring in the network, including the measurement value, and 

management control coupled to the memory to access the information indicative of the 
delays occurring in the network and to determine if a problem exists in the network that is the 
responsibility of an application service provider; 

a service provider communicatively coupled to the network device via the network, wherein 
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the service provider and management control of the network device communicate between each 
other regarding a problem associated with operation of the network application. 

72. (Previously presented) The network architecture defined in Claim 71 wherein the 
management control notifies the service provider that the problem exists and the service provider 
sends an event to address the problem. 

73. (Previously presented) The network architecture defined in Claim 72 wherein the 
service provider sends an event to fix the problem. 

74. (Previously presented) The network architecture defined in Claim 72 wherein the 
service provider sends an event to alleviate the problem. 

75. (Previously presented) The network architecture defined in Claim 74 wherein the 
network device shapes traffic in response to the event. 

76. (Previously presented) The network architecture defined in Claim 75 wherein the 
network device shapes traffic by controlling non-essential traffic. 

77. (Previously presented) The network architecture defined in Claim 71 wherein the 
network device further comprises: 

a classification engine to classify traffic in a traffic flow on the network; 
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a response time block to monitor response time; and 

a shaping block to shape traffic, wherein the measurement engine is communicatively 
coupled to the classification engine, response time block, and the shaping block to obtain 
information to create measurements by which to identify the problem with the operation of the a 
network application. 

78. (Previously presented) The network architecture defined in Claim 71 wherein the 
service provider sends an event to the network device for notification of the problem. 

79, (Previously presented) The network architecture defined in Claim 71 wherein the 
service provider allocates additional bandwidth in response to notification of the problem. 



80. (Previously presented) The network architecture defined in Claim 71 wherein the 
network device records times associated with encountering packets and acknowledgement of the 
packets to generate a measurement value. 

81. (Previously presented) The network architecture defined in Claim 71 wherein the 
network device records the sequence number of each of a plurality of packets and a time each of the 
plurality of packets reached the application layer demarcation point. 



82. (Previously presented) The network architecture defined in Claim 71 wherein the 

measurement engine performs measurements based on whether a sequence number associated with 
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an acknowledgement is equal to a sequence number of one of the previously recorded packets and 
the acknowledgement is a naked acknowledgement, and wherein the management control 
calculates a difference between the time the acknowledgement is at the demarcation point and the 
time that the data packet is originally seen at the demarcation point. 

83. (Previously presented) The network architecture defined in Claim 71 further 
comprising a customer data center coupled to a network device. 

84. (Previously presented) The network architecture defined in Claim 83 wherein the 
customer data center is coupled to a network device via a local area network. 

85. (Currently Amended) The method defined in Claim 1 wherein the first and second 
network latency conditions characterize network transmission delay condition is a delay . 

86. (Currently Amended) The method defined in Claim 33 wherein the first side is the a 
customer side and the second side is £fee a provider side. 

87. (Currently Amended) The network device defined in Claim 39 wherein the first side 
is the a customer side and the second side is the a provider side. 

88. (Currently Amended) The network device defined in Claim 71 wherein the first side 
is the a customer side and the second side is the a provider side. 
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